Update implied default for module based on target #63076
Conversation
jakebailey
requested review from
DanielRosenwasser,
RyanCavanaugh,
andrewbranch and
Copilot
typescript-bot
added
the
For Uncommitted Bug
There was a problem hiding this comment.
Pull request overview
Updates TypeScript’s implied default module compiler option to better align with the configured target, enabling more modern module semantics (e.g., top-level await) when targeting newer ECMAScript versions.
Changes:
- Adjusts computed default for
modulebased ontargetwith new thresholds (es2020/es2022/esnext). - Updates a single baseline affected by the new default (top-level await now permitted under
@target: esnextdue to implicitmodule: esnext).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/compiler/utilities.ts | Updates computed default module selection logic to track target more closely (es2015/es2020/es2022/esnext). |
| tests/baselines/reference/awaitInNonAsyncFunction.errors.txt | Updates error baseline impacted by the new implicit module default enabling top-level await under @target: esnext. |
| const target = _computedOptions.target.computeValue(compilerOptions); | ||
| if (target === ScriptTarget.ESNext) { | ||
| return ModuleKind.ESNext; | ||
| } | ||
| if (target >= ScriptTarget.ES2022) { |
There was a problem hiding this comment.
This change alters the implied module value based on target (including enabling top-level await for @target: esnext via the implicit module: esnext). It would be good to add a focused compiler test that explicitly asserts the new default mapping at the key boundaries (es2015/es2020/es2022/esnext), rather than relying on incidental baseline changes in unrelated tests.
|
@typescript-bot test top800 |
|
Hey @jakebailey, the results of running the DT tests are ready. Everything looks the same! |
|
@jakebailey Here are the results of running the top 800 repos with tsc comparing Everything looks good! |
3 participants
If
moduleis explicitly configured, we do what the config says (duh).Otherwise, if target is ES5, then
module=commonjs. Iftargetis ES2015+, thenmodule=es2015.This PR changes the default module such that:
target=esnext, thenmodule=esnext.target>=es2022, thenmodule=es2022.target>=es2020, thenmodule=es2020.target>=es2015, thenmodule=es2015.module=commonjs.This leads to potentially less strange/misaligned behavior.
Only one test changes. I could find which features each module mode enables to verify these rules, if desired.